src/ui/identities/transfer_screen.rs-502-510 (1)

502-510: ⚠️ Potential issue | 🟡 Minor

Add missing change_context implementation.

This screen implements refresh, but change_context is still missing. Please add it per the ScreenLike trait contract.
As per coding guidelines: src/ui/**/*.rs: All screens must implement the ScreenLike trait with methods: ui(), display_task_result(), display_message(), refresh()/refresh_on_arrival(), and change_context().

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/identities/transfer_screen.rs` around lines 502 - 510, The
TransferScreen impl for ScreenLike is missing the required change_context(&mut
self, ctx: ScreenContext) method; add a change_context implementation inside
impl ScreenLike for TransferScreen that matches the ScreenLike trait signature
(change_context), update TransferScreen's internal context/state as appropriate
(e.g., store the incoming ScreenContext or update fields used by
ui()/refresh()/refresh_on_arrival()), and trigger any necessary side-effects
such as scheduling a refresh or clearing/setting refresh_banner similar to
display_message/refresh behavior so the screen reacts to context changes
consistently.

src/ui/tokens/update_token_config.rs-918-934 (1)

918-934: ⚠️ Potential issue | 🟡 Minor

Implement missing ScreenLike lifecycle methods.

This impl lacks refresh/refresh_on_arrival and change_context, which are required for screens in src/ui/**/*.rs. Please add the methods (even as no-ops) per the trait signature.
As per coding guidelines: src/ui/**/*.rs: All screens must implement the ScreenLike trait with methods: ui(), display_task_result(), display_message(), refresh()/refresh_on_arrival(), and change_context().

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/update_token_config.rs` around lines 918 - 934, The impl for
UpdateTokenConfigScreen is missing the ScreenLike lifecycle methods
refresh/refresh_on_arrival and change_context; add no-op implementations that
match the ScreenLike trait signatures (i.e., implement refresh() and/or
refresh_on_arrival() and change_context() for UpdateTokenConfigScreen) alongside
the existing display_message and display_task_result methods so the type fully
implements ScreenLike. Ensure the method names and signatures exactly match the
trait used by other screens (use those files as reference) and keep bodies empty
or performing no-ops consistent with coding guidelines.

src/ui/dashpay/qr_scanner.rs-50-58 (1)

50-58: ⚠️ Potential issue | 🟡 Minor

Clear stale parsed QR data when input is empty.

If the user clears the input and clicks “Parse QR Code,” parsed_qr_data remains from a previous parse, so “Add Contact” can send outdated data. Reset it before returning.

Proposed fix

     if self.qr_data_input.is_empty() {
+        self.parsed_qr_data = None;
         crate::ui::components::MessageBanner::set_global(
             self.app_context.egui_ctx(),
             "Please enter QR code data",
             MessageType::Error,
         );
         return;
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/qr_scanner.rs` around lines 50 - 58, In parse_qr_code, when
self.qr_data_input is empty you currently show an error and return but do not
clear stale parsed_qr_data; update parse_qr_code to reset self.parsed_qr_data to
None (or the empty/default value used by the struct) before returning so the
previous parsed QR payload cannot be reused by the "Add Contact" flow; locate
the parsed_qr_data field on the same struct and clear it at the top of
parse_qr_code right before the MessageBanner and return.

docs/ai-design/2026-02-17-unified-messages/message-banner-ux-spec.md-31-35 (1)

31-35: ⚠️ Potential issue | 🟡 Minor

Add language identifiers to fenced code blocks (MD040).
This resolves markdownlint warnings and improves formatting consistency.

💡 Suggested fix

-```
+```text
 +-----------------------------------------------------------------------+
 | [Icon]  Message text here                              [5s] [x]       |
 +-----------------------------------------------------------------------+
-```
+```

-```
+```text
 +--------------------------------------------------+
 | Top Panel (header / navigation)                   |
 +--------------------------------------------------+
 | Left Panel |  [ Banner 1 ]                        |
 |            |  [ Banner 2 ]                        |
 |            |  +----- Screen Content -----+        |
 |            |  | ...                      |        |
 |            |  +--------------------------+        |
 +--------------------------------------------------+
-```
+```
</details>



Also applies to: 81-91

<details>
<summary>🤖 Prompt for AI Agents</summary>

Verify each finding against the current code and only fix it if needed.

In @docs/ai-design/2026-02-17-unified-messages/message-banner-ux-spec.md around
lines 31 - 35, Add language identifiers ("text") to the fenced code blocks for
the ASCII UI art examples so markdownlint MD040 is satisfied; update the three
backtick fences shown in the snippet (the banner box block and the larger layout
block—the same pattern also appears later around the second example) to use
text instead of and ensure each opening fence has a matching closing
fence with no extra characters removed or added.

</details>

</blockquote></details>
<details>
<summary>docs/ai-design/2026-02-17-unified-messages/architecture.md-127-139 (1)</summary><blockquote>

`127-139`: _⚠️ Potential issue_ | _🟡 Minor_

**Add language identifiers to fenced code blocks (MD040).**  
This clears markdownlint warnings and improves syntax highlighting.

<details>
<summary>💡 Suggested fix</summary>

```diff
-```
+```rust
 render_banner(ui, text, message_type, annotation: Option<&str>) -> bool (dismissed?)
 ```
 
-```
+```text
 +-----------------------------------------------------------------------+
 | [Icon]  Message text here                              [5s] [x]       |
 +-----------------------------------------------------------------------+
-```
+```

-```
+```text
 TaskResult::Error(message)
   → MessageBanner::set_global(ctx, &message, MessageType::Error)
   → screen.display_message(&message, MessageType::Error)  // for side-effects
 ```
</details>



Also applies to: 156-164

<details>
<summary>🤖 Prompt for AI Agents</summary>

Verify each finding against the current code and only fix it if needed.

In @docs/ai-design/2026-02-17-unified-messages/architecture.md around lines 127

• 139, Add explicit language identifiers to the fenced code blocks in the doc
  snippets to satisfy MD040: update the first function block to use rust for the render_banner signature (render_banner/ui/process_banner references), change the ASCII art and flow blocks to text (the visual structure box and the
  TaskResult::Error → MessageBanner::set_global → screen.display_message
  sequence), and ensure the other similar block at lines 156-164 also has a
  language identifier; no code changes required, only annotate the three fenced
  blocks with appropriate language tags.

</details>

</blockquote></details>
<details>
<summary>src/ui/tokens/tokens_screen/keyword_search.rs-63-70 (1)</summary><blockquote>

`63-70`: _⚠️ Potential issue_ | _🟡 Minor_

**Elapsed timer can carry over across searches.**

`MessageBanner::set_global` deduplicates by text, so repeating the same “Searching contracts...” banner can reuse the old `created_at` and the elapsed counter won’t reset on a new search. Consider clearing/replacing the prior banner handle before starting a new search.

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/tokens_screen/keyword_search.rs` around lines 63 - 70, The
elapsed timer can persist because MessageBanner::set_global deduplicates by
text; before creating a new banner in keyword_search (where you call
MessageBanner::set_global and assign to self.operation_banner), clear or remove
any existing banner handle stored in self.operation_banner (e.g., if let
Some(prev) = self.operation_banner.take() { prev.close() } or call the banner's
removal API) so the old banner is removed and the new handle gets a fresh
created_at; then call MessageBanner::set_global and store the new handle in
self.operation_banner as you already do.
```

</details>

</blockquote></details>
<details>
<summary>src/ui/tokens/pause_tokens_screen.rs-91-117 (1)</summary><blockquote>

`91-117`: _⚠️ Potential issue_ | _🟡 Minor_

**Fix “Burning” wording in pause authorization errors.**

These messages are shown on the Pause screen and should say “pause,” not “burn.”  

<details>
<summary>Suggested text fix</summary>

```diff
-                set_error_banner("Burning is not allowed on this token");
+                set_error_banner("Pausing is not allowed on this token");
...
-                        "You are not allowed to burn this token. Only the contract owner is.",
+                        "You are not allowed to pause this token. Only the contract owner is.",
...
-                    set_error_banner("You are not allowed to burn this token");
+                    set_error_banner("You are not allowed to pause this token");
```
</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/pause_tokens_screen.rs` around lines 91 - 117, Update the
user-facing error strings in the pause authorization checks to refer to "pause"
instead of "burn": modify the messages passed to set_error_banner in the
AuthorizedActionTakers match arms (the "Burning is not allowed on this token",
"You are not allowed to burn this token", and "You are not allowed to burn this
token. Only the contract owner is.") so they read e.g. "Pausing is not allowed
on this token", "You are not allowed to pause this token", and "You are not
allowed to pause this token. Only the contract owner is." Reference
set_error_banner, identity_token_info, and the
AuthorizedActionTakers::NoOne/ContractOwner/Identity branches to locate and
change the strings.
```

</details>

</blockquote></details>
<details>
<summary>src/ui/tokens/resume_tokens_screen.rs-279-286 (1)</summary><blockquote>

`279-286`: _⚠️ Potential issue_ | _🟡 Minor_

**Handle both Error and Warning messages to prevent stuck "resuming" state.**

The `display_message` method currently only clears `refresh_banner` and sets error state for `Error` messages. However, `Warning` messages are also emitted in the UI (they don't auto-dismiss in the banner), and should be treated identically to prevent the "Resuming tokens..." banner from continuing indefinitely.

This pattern is already established across multiple similar screen implementations (send_screen, add_contracts_screen, add_token_by_id_screen, etc.) which all handle both `Error` and `Warning` variants together.

<details>
<summary>✅ Suggested change</summary>

```diff
-        if let MessageType::Error = message_type {
+        if matches!(message_type, MessageType::Error | MessageType::Warning) {
             if let Some(h) = self.refresh_banner.take() {
                 h.clear();
             }
             self.status = ResumeTokensStatus::Error;
         }
```
</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/resume_tokens_screen.rs` around lines 279 - 286, The
display_message method only handles MessageType::Error; update it to treat
MessageType::Warning the same way so warning banners also clear and the UI
doesn't stay in "Resuming tokens..." state—locate the display_message function
and change the conditional on MessageType (e.g., use a match or matches!() to
check for MessageType::Error or MessageType::Warning), then keep the existing
behavior: take and clear self.refresh_banner (if Some) and set self.status =
ResumeTokensStatus::Error.
```

</details>

</blockquote></details>
<details>
<summary>src/ui/contracts_documents/contracts_documents_screen.rs-213-218 (1)</summary><blockquote>

`213-218`: _⚠️ Potential issue_ | _🟡 Minor_

**Clear any active query banner on parse errors.**  
If a user submits an invalid query while a previous “Querying documents…” banner is active, the stale banner remains visible. Clearing it here avoids misleading UI state.  

<details>
<summary>🐛 Suggested fix</summary>

```diff
                 Err(e) => {
+                    if let Some(h) = self.query_banner.take() {
+                        h.clear();
+                    }
                     self.document_query_status = DocumentQueryStatus::Error;
                     MessageBanner::set_global(
                         ui.ctx(),
                         &format!("Failed to parse query properly: {}", e),
                         MessageType::Error,
                     );
                 }
```
</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@src/ui/contracts_documents/contracts_documents_screen.rs` around lines 213 -
218, On parse error update, clear any existing global banner before setting the
error banner to avoid leaving the prior "Querying documents..." message visible:
in the block where you set self.document_query_status =
DocumentQueryStatus::Error and call MessageBanner::set_global(ui.ctx(), ...),
first call the MessageBanner method that removes/clears the global banner (e.g.,
MessageBanner::clear_global(ui.ctx()) or the project's equivalent) and then set
the new error banner via MessageBanner::set_global; keep the same context
ui.ctx() and the formatted error text.
```

</details>

</blockquote></details>
<details>
<summary>src/ui/dashpay/contacts_list.rs-910-913 (1)</summary><blockquote>

`910-913`: _⚠️ Potential issue_ | _🟡 Minor_

**Show a user-facing error banner when hide/unhide fails.**  
Right now failures only log, so the user gets no feedback. Consider showing a global error banner in addition to logging.  

<details>
<summary>🐛 Suggested fix</summary>

```diff
+use crate::ui::components::MessageBanner;
```

```diff
                                         if let Some(identity) = &self.selected_identity {
                                             let owner_id = identity.identity.id();
                                             if let Err(e) =
                                                 self.app_context.db.set_contact_hidden(
                                                     &owner_id,
                                                     &contact.identity_id,
                                                     new_hidden,
                                                 )
                                             {
+                                                MessageBanner::set_global(
+                                                    ui.ctx(),
+                                                    &format!("Failed to update contact: {}", e),
+                                                    MessageType::Error,
+                                                );
                                                 tracing::error!(
                                                     "Failed to update contact: {}",
                                                     e
                                                 );
                                             } else {
```
</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/contacts_list.rs` around lines 910 - 913, The error handler
that currently only calls tracing::error!("Failed to update contact: {}", e)
should also surface a user-facing global error banner: keep the tracing::error
log, then call or create a UI helper (e.g. show_error_banner or
AppState::show_global_error) to display a concise message like "Failed to
hide/unhide contact" plus the error details or a short code; do this in the same
error branch where the variable e is available so the user sees feedback when
the hide/unhide operation fails.
```

</details>

</blockquote></details>
<details>
<summary>src/ui/tokens/unfreeze_tokens_screen.rs-115-132 (1)</summary><blockquote>

`115-132`: _⚠️ Potential issue_ | _🟡 Minor_

**Update banner copy to match “unfreeze” semantics.**

These messages still reference “burning,” which is misleading in the unfreeze flow.

<details>
<summary>Proposed wording fix</summary>

```diff
-                set_error_banner("Burning is not allowed on this token");
+                set_error_banner("Unfreezing is not allowed on this token");
```

```diff
-                        "You are not allowed to burn this token. Only the contract owner is.",
+                        "You are not allowed to unfreeze this token. Only the contract owner is.",
```

```diff
-                    set_error_banner("You are not allowed to burn this token");
+                    set_error_banner("You are not allowed to unfreeze this token");
```
</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/unfreeze_tokens_screen.rs` around lines 115 - 132, The error
banners in the AuthorizedActionTakers match arms (variants NoOne, ContractOwner,
Identity) use "burn" language but this flow is for unfreezing; update calls to
set_error_banner to use unfreeze wording (e.g., "Unfreezing is not allowed on
this token", "You are not allowed to unfreeze this token", and for
ContractOwner: "You are not allowed to unfreeze this token. Only the contract
owner is.") while keeping the same guard checks against identity_token_info and
without changing control flow in those branches.
```

</details>

</blockquote></details>

</blockquote></details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

src/ui/wallets/create_asset_lock_screen.rs (1)

673-675: ⚠️ Potential issue | 🟠 Major

display_message no-op can leave the flow stuck after backend errors.

When an error arrives during WalletFundedScreenStep::WaitingForAssetLock, Line 673 currently does nothing, so the screen can remain in a perpetual waiting state.

💡 Proposed fix (preserve global banner, restore local state)

 fn display_message(&mut self, _message: &str, _message_type: MessageType) {
-    // Error/success display is handled by the global MessageBanner.
+    // Error/success display is handled by the global MessageBanner.
+    // Keep side-effects to prevent stale waiting states.
+    if matches!(_message_type, MessageType::Error | MessageType::Warning) {
+        self.is_creating = false;
+        if let Ok(mut step) = self.step.write()
+            && *step == WalletFundedScreenStep::WaitingForAssetLock
+        {
+            *step = WalletFundedScreenStep::FundsReceived;
+        }
+    }
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/wallets/create_asset_lock_screen.rs` around lines 673 - 675,
display_message currently no-ops causing the UI to stay stuck during
WalletFundedScreenStep::WaitingForAssetLock errors; modify display_message to
forward the message to the global MessageBanner (preserve existing banner
behavior) and also update the local screen state (e.g., clear the
WaitingForAssetLock flag or set the screen step to an error/idle state) so the
local flow can proceed or show retry UI; locate and update the display_message
method in create_asset_lock_screen.rs and adjust state fields used by
WalletFundedScreenStep::WaitingForAssetLock (or the local waiting flag)
accordingly.

src/ui/dashpay/qr_scanner.rs-260-260 (1)

260-260: ⚠️ Potential issue | 🟠 Major

Do not surface raw wallet errors directly to users.

This currently displays backend/internal error text as-is. Please sanitize to a stable user-facing message.

Proposed fix

-                        if let Err(e) = try_open_wallet_no_password(wallet) {
-                            MessageBanner::set_global(ui.ctx(), &e, MessageType::Error);
+                        if let Err(_e) = try_open_wallet_no_password(wallet) {
+                            MessageBanner::set_global(
+                                ui.ctx(),
+                                "Unable to access the selected wallet. Please unlock it and try again.",
+                                MessageType::Error,
+                            );
                         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/qr_scanner.rs` at line 260, The code is passing the raw
backend error variable `e` into `MessageBanner::set_global(ui.ctx(), &e,
MessageType::Error)` which surfaces internal error text to users; change this to
show a stable, sanitized user-facing message (e.g. "Unable to access wallet.
Please try again or contact support.") while logging the original `e` to the
application logs for diagnostics (use your existing logger/tracing facility).
Update the call site in `qr_scanner.rs` (the `MessageBanner::set_global`
invocation) to pass the sanitized string and add a separate log statement that
records `e` at an appropriate level.

src/ui/identities/keys/key_info_screen.rs-513-514 (1)

513-514: ⚠️ Potential issue | 🟠 Major

Don’t surface raw internal errors directly in user banners.

These banners currently expose raw error strings from wallet/storage/validation paths. Prefer a user-safe message and log full details separately.

🔒 Suggested hardening

- MessageBanner::set_global(ui.ctx(), &e, MessageType::Error);
+ tracing::warn!("try_open_wallet_no_password failed: {}", e);
+ MessageBanner::set_global(
+     ui.ctx(),
+     "Unable to access wallet right now. Please try again.",
+     MessageType::Error,
+ );

- MessageBanner::set_global(
-     self.app_context.egui_ctx(),
-     format!("Issue saving: {}", e),
-     MessageType::Error,
- );
+ tracing::warn!("update_local_qualified_identity failed: {}", e);
+ MessageBanner::set_global(
+     self.app_context.egui_ctx(),
+     "Failed to save changes.",
+     MessageType::Error,
+ );

Also applies to: 635-639, 651-655, 801-805

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/identities/keys/key_info_screen.rs` around lines 513 - 514, Several
MessageBanner::set_global(...) calls are currently passing raw internal error
strings to the UI; replace those raw errors with a concise, user-safe message
like "An unexpected error occurred" (or context-specific friendly text) and send
the full error details to your logging system instead (e.g., tracing::error! or
log::error!) so internals aren't exposed. Locate each usage of
MessageBanner::set_global in key_info_screen.rs (the calls noted around the
current occurrences) and change the banner text to a sanitized message while
calling the logger with the original error value for diagnostics. Ensure any
error formatting is not displayed to users and reuse the same pattern for the
other similar blocks in this file.

src/ui/identities/keys/key_info_screen.rs-642-656 (1)

642-656: ⚠️ Potential issue | 🟠 Major

Persist-first (or rollback) to avoid in-memory/persisted state divergence.

Both add/remove flows mutate self.identity/self.private_key_data before persistence. If update_local_qualified_identity fails, the UI state no longer reflects stored state.

💡 Suggested fix (transactional update pattern)

- self.private_key_data = Some((PrivateKeyData::Clear(private_key_bytes), None));
- self.identity.private_keys.insert_non_encrypted(
+ let mut updated_identity = self.identity.clone();
+ updated_identity.private_keys.insert_non_encrypted(
    (self.key.purpose().into(), self.key.id()),
    (self.key.clone().into(), private_key_bytes),
  );
- if let Err(e) = self.app_context.update_local_qualified_identity(&self.identity) {
+ if let Err(e) = self.app_context.update_local_qualified_identity(&updated_identity) {
     MessageBanner::set_global(
         self.app_context.egui_ctx(),
-        format!("Issue saving: {}", e),
+        "Failed to save private key changes.",
         MessageType::Error,
     );
+    return;
  }
+ self.identity = updated_identity;
+ self.private_key_data = Some((PrivateKeyData::Clear(private_key_bytes), None));

- self.private_key_data = None;
- self.identity.private_keys.private_keys.remove(&(self.key.purpose().into(), self.key.id()));
- if let Err(e) = self.app_context.update_local_qualified_identity(&self.identity) {
+ let mut updated_identity = self.identity.clone();
+ updated_identity
+     .private_keys
+     .private_keys
+     .remove(&(self.key.purpose().into(), self.key.id()));
+ if let Err(e) = self.app_context.update_local_qualified_identity(&updated_identity) {
     MessageBanner::set_global(
         ui.ctx(),
-        format!("Issue saving: {}", e),
+        "Failed to remove private key.",
         MessageType::Error,
     );
+    return;
  }
+ self.identity = updated_identity;
+ self.private_key_data = None;

Also applies to: 792-807

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/identities/keys/key_info_screen.rs` around lines 642 - 656, The code
mutates in-memory state (self.private_key_data and self.identity via
identity.private_keys.insert_non_encrypted) before calling
update_local_qualified_identity, causing UI/state divergence if persistence
fails; change to a transactional pattern: perform the persistence call
update_local_qualified_identity first using the new key data (or construct the
updated identity/keys to pass), and only on success update self.private_key_data
and self.identity in memory (or if you must mutate first, catch errors and
rollback by removing the inserted key from identity.private_keys and resetting
self.private_key_data); refer to symbols
identity.private_keys.insert_non_encrypted, self.private_key_data, and
update_local_qualified_identity to locate and apply the fix (also apply same fix
to the analogous block around lines 792-807).

src/ui/components/message_banner.rs-309-331 (1)

309-331: ⚠️ Potential issue | 🟠 Major

Text-based dedup can alias independent operations to the same handle.

Line 316 returns the existing banner key for matching text. Then Line 775 clears by key, so one caller can clear another caller’s in-flight banner if both used identical text.

Also applies to: 772-776

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/components/message_banner.rs` around lines 309 - 331, The dedup logic
in set_global (using get_banners / set_banners) returns an existing banner's key
when text matches, allowing one caller to clear another caller's banner via
BannerHandle.key; change this so text-only matches do not reuse the
existing.key: when a banner with the same text is found, do not return its
key—either update its message_type in-place but create a new Banner entry with a
freshly generated key (or otherwise generate a new unique key for the caller)
and push it to banners, then call set_banners(ctx, banners) and return a
BannerHandle with the new key; reference the set_global function, existing.key,
BannerHandle and get_banners/set_banners when locating where to implement the
change.

src/ui/tokens/freeze_tokens_screen.rs-333-338 (1)

333-338: ⚠️ Potential issue | 🟠 Major

Scope display_message side-effects to active freeze operations only.

Lines 335-338 set FreezeTokensStatus::Error for any warning/error. Unrelated global messages can incorrectly change this screen’s state.

Suggested fix

     fn display_message(&mut self, _message: &str, message_type: MessageType) {
         // Banner display is handled globally by AppState; this is only for side-effects.
         if matches!(message_type, MessageType::Error | MessageType::Warning) {
-            self.refresh_banner.take_and_clear();
-            self.status = FreezeTokensStatus::Error;
+            if matches!(self.status, FreezeTokensStatus::WaitingForResult) {
+                self.refresh_banner.take_and_clear();
+                self.status = FreezeTokensStatus::Error;
+            }
         }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/freeze_tokens_screen.rs` around lines 333 - 338,
display_message currently clears refresh_banner and sets status to
FreezeTokensStatus::Error for any Warning/Error; restrict these side-effects to
only when the screen has an active freeze operation. Update display_message (the
method shown) to first check that this screen is handling an active freeze (e.g.
verify a pending refresh via self.refresh_banner.is_some() or an existing
active/freezing flag on the struct) and only then call
self.refresh_banner.take_and_clear() and set self.status =
FreezeTokensStatus::Error; otherwise ignore unrelated global messages. Ensure
you reference the existing symbols display_message, self.refresh_banner, and
FreezeTokensStatus::Error when making the change.

src/ui/dashpay/qr_code_generator.rs-125-129 (1)

125-129: ⚠️ Potential issue | 🟠 Major

Sanitize backend error details before showing QR generation failures.

On Line 127, the raw error is shown directly to users. This can leak internal details and unstable diagnostics.

Suggested fix

                 Err(e) => {
-                    MessageBanner::set_global(
-                        self.app_context.egui_ctx(),
-                        format!("Failed to generate QR code: {}", e),
-                        MessageType::Error,
-                    );
+                    tracing::error!("Failed to generate QR code: {e}");
+                    MessageBanner::set_global(
+                        self.app_context.egui_ctx(),
+                        "Failed to generate QR code. Please try again.",
+                        MessageType::Error,
+                    );
                 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/qr_code_generator.rs` around lines 125 - 129, The code
currently passes the raw backend error into MessageBanner::set_global (call
using self.app_context.egui_ctx() and format!("Failed to generate QR code: {}",
e)), which can leak internal details; change it to show a generic, sanitized
user-facing message like "Failed to generate QR code. Please try again or
contact support." and move the detailed error into a developer log (e.g., use
log::error! or processLogger.error) so MessageBanner only displays the generic
text while the original error `e` is recorded in logs for debugging.

src/ui/tools/transition_visualizer_screen.rs-394-399 (1)

394-399: ⚠️ Potential issue | 🟠 Major

Do not reset broadcast state on unrelated warning/error messages.

Lines 394-397 currently clear submit_banner and reset to NotStarted for any warning/error. This can interrupt active flow and re-enable submit prematurely.

Suggested fix

-    fn display_message(&mut self, _message: &str, message_type: MessageType) {
+    fn display_message(&mut self, message: &str, message_type: MessageType) {
         // Banner display is handled globally by AppState; this is only for side-effects.
         match message_type {
             MessageType::Success => {
                 if matches!(self.broadcast_status, TransitionBroadcastStatus::Submitting) {
                     self.submit_banner.take_and_clear();
                     self.broadcast_status = TransitionBroadcastStatus::Complete(Instant::now());
                 }
             }
             MessageType::Error | MessageType::Warning => {
-                self.submit_banner.take_and_clear();
-                self.broadcast_status = TransitionBroadcastStatus::NotStarted;
+                if matches!(self.broadcast_status, TransitionBroadcastStatus::Submitting) {
+                    self.submit_banner.take_and_clear();
+                    self.broadcast_status =
+                        TransitionBroadcastStatus::Error(message.to_string(), Instant::now());
+                }
             }
             MessageType::Info => {}
         }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tools/transition_visualizer_screen.rs` around lines 394 - 399, The
current match arm for MessageType::Error | MessageType::Warning unconditionally
calls self.submit_banner.take_and_clear() and resets self.broadcast_status to
TransitionBroadcastStatus::NotStarted, which disrupts active broadcasts; change
this to only clear the banner and reset broadcast_status when the warning/error
is actually related to the transition broadcast. Concretely, in the
MessageType::Error | MessageType::Warning branch add a guard that verifies the
submit_banner corresponds to a broadcast failure (e.g. check a new or existing
metadata field on self.submit_banner, or inspect the banner message text via a
helper like submit_banner.is_broadcast_error()) and only then call
self.submit_banner.take_and_clear() and set self.broadcast_status =
TransitionBroadcastStatus::NotStarted; otherwise leave the banner and
broadcast_status untouched. Ensure you update or add the minimal helper on the
submit_banner type if necessary to identify broadcast-related messages.

src/ui/contracts_documents/document_action_screen.rs-512-516 (1)

512-516: ⚠️ Potential issue | 🟠 Major

Reset action state when document ID parsing fails.

Line 512 and Line 581 only show a banner; they don’t clear previously fetched state. That leaves stale fetched_price/original_doc paths active and can enable unintended broadcasts after invalid input.

Suggested fix

             } else {
                 MessageBanner::set_global(
                     ui.ctx(),
                     "Invalid Document ID format",
                     MessageType::Error,
                 );
+                self.fetched_price = None;
+                self.broadcast_status = BroadcastStatus::NotBroadcasted;
             }

                 } else {
                     MessageBanner::set_global(
                         ui.ctx(),
                         "Invalid Document ID format",
                         MessageType::Error,
                     );
+                    self.original_doc = None;
+                    self.field_inputs.clear();
+                    self.broadcast_status = BroadcastStatus::NotBroadcasted;
                 }

Also applies to: 581-585

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/contracts_documents/document_action_screen.rs` around lines 512 - 516,
When parsing the Document ID fails (where MessageBanner::set_global("Invalid
Document ID format", MessageType::Error) is called) also reset the action state
to avoid stale data: clear or set to None the fetched_price and original_doc
fields and reset any broadcast/enabled flags or paths that depend on a valid
document (e.g., disable/clear broadcast_path or set can_broadcast = false).
Apply the same reset logic at the other parse-failure site where the banner is
shown so both code paths clear fetched_price, original_doc and any
broadcast-related state in the DocumentActionScreen struct before returning.

src/ui/tokens/mod.rs-24-30 (1)

24-30: ⚠️ Potential issue | 🟠 Major

Do not downgrade identity-load failures to an empty list.

Line 29 (unwrap_or_default) masks load/corruption errors and allows token flows to proceed with silently missing identities. This should return/propagate the error so callers can bail explicitly.

Suggested direction

-pub fn load_identities_with_banner(app_context: &AppContext) -> Vec<QualifiedIdentity> {
+pub fn load_identities_with_banner(
+    app_context: &AppContext,
+) -> Result<Vec<QualifiedIdentity>, String> {
     use crate::ui::components::ResultBannerExt;
     app_context
         .load_local_qualified_identities()
         .or_show_error(app_context.egui_ctx())
-        .unwrap_or_default()
 }

Then make callers early-return on Err.

Based on learnings: In src/database/identities.rs, identity-loading paths intentionally abort on the first corrupted blob because skipping/masking corruption can lead to fund loss.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/mod.rs` around lines 24 - 30, In load_identities_with_banner
replace the current unwrap_or_default behavior so it returns a
Result<Vec<QualifiedIdentity>, E> (propagating the error from
app_context.load_local_qualified_identities().or_show_error(...)) instead of
silently returning an empty list; update the function signature and callers to
handle Err (early-return where identities are required) and preserve the use of
or_show_error/app_context.egui_ctx() when converting or displaying the error
from load_local_qualified_identities.

src/app.rs-1030-1037 (1)

1030-1037: ⚠️ Potential issue | 🟠 Major

Do not force all BackendTaskSuccessResult::Message payloads into a success banner.

Line 1035 always shows a success banner, but these message payloads are also interpreted as errors by some screens, causing contradictory UX (success flash followed by error). Route message severity explicitly instead of hardcoding MessageType::Success.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app.rs` around lines 1030 - 1037, Currently
BackendTaskSuccessResult::Message always calls MessageBanner::set_global with
MessageType::Success, which forces every message into a success banner; instead,
determine and pass the correct severity for the message (either by adding a
severity field to BackendTaskSuccessResult::Message or by extracting severity
from the existing unboxed_message) and call MessageBanner::set_global with that
computed MessageType rather than MessageType::Success; update the
BackendTaskSuccessResult::Message variant and the handling code (the match arm
that calls MessageBanner::set_global and
visible_screen_mut().display_task_result) so the banner reflects the message's
explicit severity.

src/ui/tools/masternode_list_diff_screen.rs-4149-4153 (1)

4149-4153: ⚠️ Potential issue | 🟠 Major

Remove local error rendering side-effect from display_message to avoid duplicate banners.

On Line 4152, setting self.ui_state.error still triggers the inline error banner, so users can see both local and global errors for the same event. Keep only non-visual side effects here (e.g., clearing pending state).

Suggested minimal fix

 fn display_message(&mut self, message: &str, message_type: MessageType) {
     // Banner display is handled globally by AppState; this is only for side-effects.
     if matches!(message_type, MessageType::Error | MessageType::Warning) {
         self.task.pending = None;
-        self.ui_state.error = Some(message.to_string());
     }
 }

As per coding guidelines: "Use MessageBanner for user-facing messages and let island_central_panel() render global banners centrally".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tools/masternode_list_diff_screen.rs` around lines 4149 - 4153, In
display_message (the block matching message_type against MessageType::Error |
MessageType::Warning) remove the visual side-effect that sets
self.ui_state.error and only perform non-visual updates: keep self.task.pending
= None but delete the assignment self.ui_state.error =
Some(message.to_string()); let global banner rendering remain handled by
AppState/MessageBanner and island_central_panel().

src/ui/dashpay/add_contact_screen.rs-623-625 (1)

623-625: ⚠️ Potential issue | 🟠 Major

Do not rely on fragile substring matching for backend error classification.

If backend wording changes, Line 626’s heuristic can miss errors and leave the screen stuck in Sending. Add a fallback that always transitions out of sending state when a message arrives during an active send flow.

Suggested guard to avoid sticky Sending state

             BackendTaskSuccessResult::Message(message) => {
                 // TODO(RUST-004): Replace string-based error matching with structured
                 // error types through the task result system. This is fragile — if
                 // upstream error wording changes, classification silently breaks.
                 if message.contains("Error")
                     || message.contains("Failed")
                     || message.contains("does not have")
                 {
                     // Try to parse structured error, fallback to generic
                     let error = if message.contains("ENCRYPTION key") {
                         DashPayError::MissingEncryptionKey
                     } else if message.contains("DECRYPTION key") {
                         DashPayError::MissingDecryptionKey
                     } else if message.contains("not found") && message.contains("username") {
                         DashPayError::UsernameResolutionFailed {
                             username: self.username_or_id.clone(),
                         }
                     } else if message.contains("Identity not found") {
                         DashPayError::IdentityNotFound {
                             identity_id: dash_sdk::platform::Identifier::from_string(
                                 &self.username_or_id,
                                 dash_sdk::dpp::platform_value::string_encoding::Encoding::Base58,
                             )
                             .unwrap_or_else(|_| dash_sdk::platform::Identifier::random()),
                         }
                     } else if message.contains("Network") || message.contains("connection") {
                         DashPayError::NetworkError {
                             reason: message.clone(),
                         }
                     } else {
                         DashPayError::Internal {
                             message: message.clone(),
                         }
                     };

                     self.status = ContactRequestStatus::Error(error);
+                } else if matches!(self.status, ContactRequestStatus::Sending) {
+                    self.status = ContactRequestStatus::Error(DashPayError::Internal {
+                        message: message.clone(),
+                    });
                 }
                 // Ignore other messages - they're not for this screen
             }

Also applies to: 626-659

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/add_contact_screen.rs` around lines 623 - 625, The current
backend-error classification in add_contact_screen.rs relies on fragile
substring matching of the "Sending" flow (see TODO(RUST-004)); modify the
message-handling code (the branch that checks for backend error strings between
lines ~626-659) to always clear the sending state as a fallback: whenever any
backend message arrives while the UI is in the Sending state, set the UI to a
non-sending state (e.g., mark sending=false or transition to Idle/Error/Success
as appropriate) so the screen cannot become permanently stuck; keep the planned
migration to structured task results (TODO(RUST-004>) but implement this
unconditional fallback in the function that processes backend messages/ task
results (the handler around the current substring check) and add a debug log for
unexpected messages to aid future refactors.

src/ui/contracts_documents/group_actions_screen.rs-262-268 (1)

262-268: ⚠️ Potential issue | 🟠 Major

Avoid dropping fetched results on row-level action errors.

Line [262] and Line [275] set fetch_group_actions_status = FetchGroupActionsStatus::Error when preparing a single “Take Action” flow fails. That hides the already-fetched table and forces a refetch, even though fetch itself succeeded.

Proposed fix

-                                                self.fetch_group_actions_status =
-                                                    FetchGroupActionsStatus::Error;
                                                 MessageBanner::set_global(
                                                     ui.ctx(),
                                                     "No identity token balance found",
                                                     MessageType::Error,
                                                 );
@@
-                                                self.fetch_group_actions_status =
-                                                    FetchGroupActionsStatus::Error;
                                                 MessageBanner::set_global(
                                                     ui.ctx(),
                                                     format!("Failed to get identity token info: {}", e),
                                                     MessageType::Error,
                                                 );

Also applies to: 275-281

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/contracts_documents/group_actions_screen.rs` around lines 262 - 268,
The code currently sets self.fetch_group_actions_status =
FetchGroupActionsStatus::Error in the row-level "Take Action" failure branches
(around the blocks that call MessageBanner::set_global with "No identity token
balance found"), which incorrectly hides the already-fetched table and forces a
refetch; instead, remove the assignment to fetch_group_actions_status in those
error paths and only emit the user-facing error via
MessageBanner::set_global(ui.ctx(), ...). If you need to represent per-row
action state, set or introduce a separate field (e.g.,
self.take_group_action_status or an ActionRowStatus enum) and update that
instead of FetchGroupActionsStatus, leaving fetch_group_actions_status untouched
when fetch succeeded. Ensure you update both error blocks mentioned (the one
around lines 262 and the one around lines 275-281) and keep MessageBanner usage
and ui.ctx() as-is.

src/ui/dashpay/contact_info_editor.rs-288-290 (1)

288-290: ⚠️ Potential issue | 🟠 Major

Reset saving on error/warning messages to avoid stuck spinner.

After Line [97] sets self.saving = true, backend failures typically arrive via display_message. With Line [288] as a no-op, the screen can stay in “Saving...” indefinitely.

Proposed fix

-    pub fn display_message(&mut self, _message: &str, _message_type: MessageType) {
+    pub fn display_message(&mut self, _message: &str, message_type: MessageType) {
         // Banner display is handled globally by AppState; this is only for side-effects.
+        if matches!(message_type, MessageType::Error | MessageType::Warning) {
+            self.saving = false;
+        }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/contact_info_editor.rs` around lines 288 - 290, The
display_message method currently does nothing, causing self.saving to remain
true after backend failures; update fn display_message(&mut self, _message:
&str, message_type: MessageType) to clear the saving flag on non-success
outcomes by setting self.saving = false when message_type indicates Error or
Warning (leave Success/Info behaviors unchanged), and keep any existing note
about global banner handling for AppState; reference the display_message method
and the struct field saving to locate where to add this change.

src/ui/dashpay/send_payment.rs-786-788 (1)

786-788: ⚠️ Potential issue | 🟠 Major

PaymentHistory can remain stuck in loading state on backend errors.

Line [576] sets loading = true, but Line [786] no longer clears it when failures arrive through the message path.

Proposed fix

-    pub fn display_message(&mut self, _message: &str, _message_type: MessageType) {
+    pub fn display_message(&mut self, _message: &str, _message_type: MessageType) {
         // Banner display is handled globally by AppState; this is only for side-effects.
+        self.loading = false;
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/send_payment.rs` around lines 786 - 788, The PaymentHistory
display_message implementation currently does nothing, causing self.loading to
stay true when backend errors are delivered via messages; update the
PaymentHistory::display_message method in src/ui/dashpay/send_payment.rs to
clear the loading flag (self.loading = false) and set an appropriate error state
when a failure message arrives—inspect the MessageType enum (or the message
text) to detect error/failure cases and ensure you update self.error or similar
fields and reset any loading indicator so the UI unblocks.

src/ui/contracts_documents/group_actions_screen.rs-460-466 (1)

460-466: ⚠️ Potential issue | 🟠 Major

Scope error side-effects to active fetch state.

Line [463] currently flips to Error for any warning/error delivered to this screen. Unrelated global errors can clear a valid Complete(...) result view.

Proposed fix

-    fn display_message(&mut self, _message: &str, message_type: MessageType) {
+    fn display_message(&mut self, _message: &str, message_type: MessageType) {
         // Banner display is handled globally by AppState; this is only for side-effects.
-        match message_type {
-            MessageType::Error | MessageType::Warning => {
-                self.fetch_banner.take_and_clear();
-                self.fetch_group_actions_status = FetchGroupActionsStatus::Error;
-            }
-            MessageType::Success | MessageType::Info => {}
+        if matches!(self.fetch_group_actions_status, FetchGroupActionsStatus::WaitingForResult)
+            && matches!(message_type, MessageType::Error | MessageType::Warning)
+        {
+            self.fetch_banner.take_and_clear();
+            self.fetch_group_actions_status = FetchGroupActionsStatus::Error;
         }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/contracts_documents/group_actions_screen.rs` around lines 460 - 466,
In display_message, avoid flipping fetch_group_actions_status to Error for
unrelated global warnings/errors; instead, only perform the side-effects
(self.fetch_banner.take_and_clear() and set fetch_group_actions_status =
FetchGroupActionsStatus::Error) when the screen is actively fetching or in a
non-final state—i.e., guard the MessageType::Error | MessageType::Warning arm
with a check against the current self.fetch_group_actions_status (allow mutation
only for FetchGroupActionsStatus variants representing in-progress/pending
states, not Complete), so existing Complete results are not cleared by unrelated
errors.

src/ui/contracts_documents/contracts_documents_screen.rs-543-550 (1)

543-550: ⚠️ Potential issue | 🟠 Major

Don’t key query failure state on message text.

Line [545] relies on "Error fetching documents" substring matching. If backend wording changes, this screen can remain WaitingForResult with stale elapsed banner and no state transition.

Proposed fix

-    fn display_message(&mut self, message: &str, message_type: MessageType) {
+    fn display_message(&mut self, _message: &str, message_type: MessageType) {
         // Banner display is handled globally by AppState; this is only for side-effects.
-        if message.contains("Error fetching documents")
-            && matches!(message_type, MessageType::Error | MessageType::Warning)
-        {
+        if matches!(self.document_query_status, DocumentQueryStatus::WaitingForResult)
+            && matches!(message_type, MessageType::Error | MessageType::Warning)
+        {
             self.query_banner.take_and_clear();
             self.document_query_status = DocumentQueryStatus::Error;
         }
     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/contracts_documents/contracts_documents_screen.rs` around lines 543 -
550, display_message currently keys query failure logic on a string match of
"Error fetching documents", which is brittle; update the handling to rely on a
structured signal instead: add a dedicated variant like MessageType::QueryFailed
(or MessageType::DocumentQueryError) to the MessageType enum and change
display_message to check for that variant (matches!(message_type,
MessageType::QueryFailed)) when deciding to call
self.query_banner.take_and_clear() and set self.document_query_status =
DocumentQueryStatus::Error; this ensures the screen transitions correctly
without depending on backend wording.

src/ui/dashpay/contacts_list.rs-1036-1040 (1)

1036-1040: ⚠️ Potential issue | 🟠 Major

Stop swallowing database write failures in contact sync paths.

These let _ = ... calls suppress persistence errors and can leave cache/state silently inconsistent after a fetch or profile update.

🛠️ Suggested fix pattern

- let _ = self
-     .app_context
-     .db
-     .clear_dashpay_contacts(&owner_id, &network_str);
+ if let Err(e) = self
+     .app_context
+     .db
+     .clear_dashpay_contacts(&owner_id, &network_str)
+ {
+     tracing::error!("Failed to clear cached contacts for {}: {}", owner_id, e);
+     MessageBanner::set_global(
+         self.app_context.egui_ctx(),
+         "Failed to refresh contacts cache",
+         MessageType::Error,
+     );
+     return;
+ }

- let _ = self.app_context.db.save_dashpay_contact(
+ if let Err(e) = self.app_context.db.save_dashpay_contact(
      &owner_id,
      &contact_data.identity_id,
      &network_str,
      contact_data.username.as_deref(),
      contact_data.display_name.as_deref(),
      contact_data.avatar_url.as_deref(),
      None,
      "accepted",
- );
+ ) {
+     tracing::error!("Failed to save cached contact {}: {}", contact_data.identity_id, e);
+ }

Also applies to: 1065-1074, 1078-1085, 1154-1163

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/contacts_list.rs` around lines 1036 - 1040, The code is
currently swallowing persistence errors by using "let _ =
self.app_context.db.clear_dashpay_contacts(&owner_id, &network_str);" which can
leave cache/state inconsistent; change calls to clear_dashpay_contacts (and
other DB write calls in the contact sync paths) to handle the Result: check for
Err, log the error with context (include owner_id and network_str) via the
existing logger, and propagate or return the error upstream (or at minimum mark
sync as failed) instead of discarding it; apply the same pattern to the other
occurrences around the contact sync (the calls at lines referenced in the
review: the similar DB writes at 1065-1074, 1078-1085, 1154-1163).

src/ui/dashpay/contacts_list.rs-1077-1085 (1)

1077-1085: ⚠️ Potential issue | 🟠 Major

Persist private contact data even when nickname is empty.

Saving private info only when nickname is present drops note/is_hidden updates for contacts without a nickname.

🛠️ Proposed fix

- if let Some(nickname) = &contact_data.nickname {
-     let _ = self.app_context.db.save_contact_private_info(
-         &owner_id,
-         &contact_data.identity_id,
-         nickname,
-         &contact_data.note.unwrap_or_default(),
-         contact_data.is_hidden,
-     );
- }
+ if contact_data.nickname.is_some() || contact_data.note.is_some() || contact_data.is_hidden {
+     let nickname = contact_data.nickname.as_deref().unwrap_or("");
+     let note = contact_data.note.as_deref().unwrap_or("");
+     if let Err(e) = self.app_context.db.save_contact_private_info(
+         &owner_id,
+         &contact_data.identity_id,
+         nickname,
+         note,
+         contact_data.is_hidden,
+     ) {
+         tracing::error!(
+             "Failed to save private contact info for {}: {}",
+             contact_data.identity_id,
+             e
+         );
+     }
+ }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/dashpay/contacts_list.rs` around lines 1077 - 1085, The code only
calls self.app_context.db.save_contact_private_info when contact_data.nickname
is Some, which drops updates to note/is_hidden for contacts without nicknames;
change it to always call save_contact_private_info using the
contact_data.nickname defaulted to an empty string (e.g. via
contact_data.nickname.as_deref().unwrap_or_default() or
contact_data.nickname.unwrap_or_default()), passing owner_id,
contact_data.identity_id, the computed nickname,
&contact_data.note.unwrap_or_default(), and contact_data.is_hidden so
note/is_hidden are persisted even when nickname is empty.

src/ui/tokens/claim_tokens_screen.rs-85-97 (1)

85-97: ⚠️ Potential issue | 🟠 Major

Do not fallback to an arbitrary identity when target identity is missing.

Line 96 falls back to the first local identity after an error. That can route a claim through the wrong identity/key set and produce unintended token operations.

🛠️ Suggested fix

-        let identity = known_identities
-            .iter()
-            .find(|id| id.identity.id() == identity_token_basic_info.identity_id)
-            .cloned()
-            .or_else(|| {
-                MessageBanner::set_global(
-                    app_context.egui_ctx(),
-                    "Identity not found in local store",
-                    MessageType::Error,
-                );
-                // Fallback to first available identity for degraded state.
-                known_identities.first().cloned()
-            });
+        let identity = known_identities
+            .iter()
+            .find(|id| id.identity.id() == identity_token_basic_info.identity_id)
+            .cloned();
+
+        if identity.is_none() {
+            MessageBanner::set_global(
+                app_context.egui_ctx(),
+                "Identity not found in local store",
+                MessageType::Error,
+            );
+        }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/claim_tokens_screen.rs` around lines 85 - 97, The code
currently falls back to known_identities.first().cloned() when the identity
lookup (using known_identities.iter().find(...) against
identity_token_basic_info.identity_id) fails, which can route actions through
the wrong key; remove that fallback and ensure the lookup returns None while
still showing the error banner via
MessageBanner::set_global(app_context.egui_ctx(), ...). Concretely: stop using
or_else(...) that returns first().cloned(); instead perform the
.find(...).cloned(), check if the result is None, call
MessageBanner::set_global(...) to surface the error, and propagate/handle the
None identity so no implicit fallback identity is used (update any downstream
code to handle the Option accordingly).

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

src/ui/wallets/send_screen.rs:1

• handle.with_elapsed() returns a value (likely &BannerHandle or a builder) but the return value is discarded. If with_elapsed() is a builder method that must be stored to take effect, the elapsed timer will never start. The pattern used elsewhere in the codebase (e.g. in token_creator.rs) calls handle.with_elapsed() and then stores self.operation_banner = Some(handle), which is what this function does — however, if with_elapsed returns a new handle or mutates through a returned reference and the original handle is what gets stored, this is correct. But if with_elapsed is a consuming builder, the stored handle would be missing the elapsed configuration. Please verify the return type of with_elapsed() and confirm that storing the pre-call handle captures the elapsed timer state.
  src/ui/wallets/single_key_send_screen.rs:1
• The return statement was removed from this branch. Previously the function returned early after showing the fee confirmation dialog, preventing the message from being stored. Now execution continues to fall through to the end of the function, which no longer stores a message. While no message is stored (the storage was removed), the sending state reset logic above this block (lines 936–940) may now incorrectly execute for relay-fee errors — self.sending = false would be set even for relay-fee errors that should keep the sending state alive. The original comment said "Keep sending state true until user confirms or cancels", but removing return means the sending state check at lines 936–940 runs first and may clear it.
  src/ui/tokens/tokens_screen/keyword_search.rs:1
• This manual take-and-clear pattern is used in several other files via self.operation_banner.take_and_clear() (using the OptionBannerExt trait). For consistency with the rest of the codebase, this should use self.operation_banner.take_and_clear() instead.
  src/ui/wallets/single_key_send_screen.rs:1
• self.fee_dialog.pending_request = None was added here in display_task_result but the original display_message call (now replaced with a direct set_global) was the mechanism that also cleared the fee dialog state in the original code. If a success result comes in while the fee dialog is open, pending_request is cleared. However if the banner is set via AppState and display_task_result is called, there may be a double-clear or ordering issue depending on the call sequence. This is likely correct, but worth verifying that pending_request doesn't need to be cleared in display_message as well (for the error path).
  src/ui/tools/transition_visualizer_screen.rs:1
• Previously, when an error occurred the broadcast status was set to TransitionBroadcastStatus::Error(message.to_string(), Instant::now()), which preserved the error message and timestamp for display. Now it resets to NotStarted, discarding the error info entirely. The Error(String, Instant) variant still exists in the enum (line 29 in the diff context) but is never set anymore. The fade-effect rendering for the error state (which was noted in the PR description as being intentionally preserved) would now never trigger. Please verify this is intentional or restore the Error variant assignment.